docs: color palette aliases design decisions - #22
Merged
Conversation
Co-authored-by: Jack Granatowski <contact@codeslash.net>
📝 WalkthroughWalkthroughThis PR adds a design document proposing a semantic color alias layer for SLASHED. The specification defines expanded numeric and alpha scales, shade and functional aliases per brand color, status color tokens, and a var()-based remapping mechanism to allow runtime overrides. ChangesColor Alias Design Specification
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
docs/color-aliases-design-decisions.md (1)
177-179: ⚡ Quick winResolve token coexistence strategy before implementation handoff.
Line 178 leaves a core contract open (
--sf-color-{status}-*vs--sf-status-{x}-bg/text/border). Add an explicit decision (replace, alias, or coexist) plus migration rule to avoid divergent implementations.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/color-aliases-design-decisions.md` around lines 177 - 179, Decide and document a single coexistence strategy for the color-status tokens: explicitly state whether `--sf-color-{status}-subtle/muted/strong` will replace, alias to, or coexist with the existing `--sf-status-{x}-bg/text/border`, and add a clear migration rule (e.g., "alias for N releases then replace", or "coexist with priority order and deprecation timeline") so implementers know how to map `--sf-status-{x}-bg/text/border` to `--sf-color-{status}-*`; also clarify the rule for `500` palette values (literal `var(--sf-color-primary)` vs color-mix pattern) and prescribe the canonical form to use across the palette to avoid divergent implementations.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/color-aliases-design-decisions.md`:
- Around line 50-58: The markdown fence blocks that list the design token scale
(e.g., the block containing lines like "--sf-color-{color}-superlight → 50" and
the other similar blocks around the later color lists) are missing fence
languages and trigger MD040; update each fenced code block (the three blocks
that show the color scale and the other blocks covering the ranges mentioned) to
include a language tag such as "css" (e.g., replace ``` with ```css) so the code
fences are annotated for the linter.
---
Nitpick comments:
In `@docs/color-aliases-design-decisions.md`:
- Around line 177-179: Decide and document a single coexistence strategy for the
color-status tokens: explicitly state whether
`--sf-color-{status}-subtle/muted/strong` will replace, alias to, or coexist
with the existing `--sf-status-{x}-bg/text/border`, and add a clear migration
rule (e.g., "alias for N releases then replace", or "coexist with priority order
and deprecation timeline") so implementers know how to map
`--sf-status-{x}-bg/text/border` to `--sf-color-{status}-*`; also clarify the
rule for `500` palette values (literal `var(--sf-color-primary)` vs color-mix
pattern) and prescribe the canonical form to use across the palette to avoid
divergent implementations.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: df24b1a3-164c-4d82-b220-964299c99703
📒 Files selected for processing (1)
docs/color-aliases-design-decisions.md
Comment on lines
+50
to
+58
| ``` | ||
| --sf-color-{color}-superlight → 50 | ||
| --sf-color-{color}-xlight → 200 | ||
| --sf-color-{color}-lighter → 400 | ||
| [base = 500 = --sf-color-{color}] | ||
| --sf-color-{color}-darker → 600 | ||
| --sf-color-{color}-xdark → 800 | ||
| --sf-color-{color}-superdark → 950 | ||
| ``` |
There was a problem hiding this comment.
Add fence languages to code blocks to satisfy markdown linting.
Line 50, Line 76, and Line 95 use fenced blocks without a language, which triggers MD040 and can fail doc CI in stricter setups. Please annotate them (e.g., css).
Also applies to: 76-82, 95-99
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 50-50: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/color-aliases-design-decisions.md` around lines 50 - 58, The markdown
fence blocks that list the design token scale (e.g., the block containing lines
like "--sf-color-{color}-superlight → 50" and the other similar blocks around
the later color lists) are missing fence languages and trigger MD040; update
each fenced code block (the three blocks that show the color scale and the other
blocks covering the ranges mentioned) to include a language tag such as "css"
(e.g., replace ``` with ```css) so the code fences are annotated for the linter.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request was created by @kiro-agent on behalf of @jackgranatowski 👻
Comment with /kiro fix to address specific feedback or /kiro all to address everything.
Learn about Kiro autonomous agent
Summary
Adds a design decisions document for the upcoming semantic color alias layer in
tokens.palette.css.Key decisions documented:
superlight,xlight,lighter,darker,xdark,superdarkhover,active,subtle,muted,ghostsubtle,muted,strong)var(), user overrides propagate globallyOpen questions for review:
hover,active) vs existing--sf-color-bg--hoverin core - different scope, confirm no confusion--sf-status-{x}-bg/text/border- replace, alias, or coexist?500token implementation: literalvar()reference orcolor-mix()for consistency?No code changes - documentation only for team review before implementation.
Summary by CodeRabbit